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(54) Processing transactions using card 



(57) A method of processing transactions by a 
transaction processor connected to companies of 
different industries via a network, 5, enables the 
performance of a variety of transactions related to 
insurance utilizing one or plural cards. In the invention the 
insurance card of a transactor is input, 12, and a 
transaction screen including transaction keys related to 
preset transactions proper to the transactor is displayed. 
A transaction key showing a desired transaction is 
selected on the displayed screen and another card or 
other plural cards required for the desired transaction are 
input sequentially. The personal identification numbers of 
the cards are entered, and loan, inquiry, payment of 
insurance, contract, voi dance/cancellation of a contract or 
payment of a premium transactions can be executed. 
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2310944 

METHOD OF PROCESSING PLURAL TYPES OF TRANSACTIONS USING CARD 



The present invention relates to a method, apparatus 
5 and computer program, for processing plural types of 

transactions using cards- More particularly, the present 
invention relates to a method, apparatus and computer program 
for processing a variety of transactions using one or plural 
cards in an efficient manner by a transaction processor 
10 connected to plural institutions of different industries such 
as an insurance company, a bank, a credit card issuance 
company, a loan office and other financial institutions via a 
network . 

A system for utilizing an automatic transaction 
15 processor such as an automatic teller machine (ATM) and 

performing a variety of transactions with a transactor is well 
know. Such a system is described on pages 57 to 71 of 
Financial Journal published in Dec, 1995 is well known. This 
system is for utilizing a transaction card owned by a 
2 n transactor such as a debit card issued by a bank via ATM to 

receive regular services of a bank such as withdrawal, deposit 
and transfer provided by ATM as other transactors. 

A system for freely performing a variety of 
transactions among companies of different industries is also 
25 well known. Such a system is described in "Creating Electronic 
Commerce By The Internet" by T. Kimura, et al., Nikkei 
Multimedia, July, 1995, pp. 139-154. In this system, 
attribute/transaction information held in a common server is 
managed individually and a user can access to transaction 

\ 
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information freely. 

Further, a system utilizing electronic money in 
payment is well known. Such a system described In "MODEX Will 
Expand the MONDEX System in Britain After Two Years" by Y. 
5 Ochi, Financial Journal, Jan., 1996. This system is for paying 
money by sending or receiving electronic money which is an 
electronic symbol of money and is stored in an IC chip embedded 
in a conventional plastic card. 

The conventional method has the following problems: 

10 If an insurance transaction such as loan and inquiry 

is performed utilizing an ATM operated by an insurance company, 
only one card issued by the insurance company is used for the 
transaction with the insurance company. However, if the 
contract of a new insurance via ATM in cooperation with a bank 

15 and a credit card issuance company, a loan based upon the 

contract of an insurance and a bank account and inquiry of an 
insurance, a bank account or a credit card are performed, 
transaction processing is required to be executed individual 
using each card. Such a processing is not very efficient. 

2 n Personal identification numbers are required for each 

card for every industry. If personal identification numbers 
for each card are different then each of these different 
personal identification numbers are required to be entered in 
order to perform a required processing. For the user such a 

25 requirement is inconvenient. 

There is also a problem that the types and 
arrangement of transaction keys on the transaction screen of an 
ATM are fixed for all customers and transactions. Thus, a 

2 
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undesired transaction key is displayed in a main location of 
the screen and a transaction desired by a transactor cannot be 
necessarily performed efficiently. 



An object of the present invention is to provide a 
method, apparatus and computer program for processing plural 
types of transactions using cards wherein plural cards of 
different industries can be utilized at one transaction 
10 terminal and a variety of insurance transactions can be 
efficiently performed. 

Another object of the present invention is to provide 
a method, apparatus and computer program for processing plural 
types of transactions using cards wherein if plural cards are 
15 used, only the entry of the personal identification numbers of 
an insurance card and a bank card for payment is required and 
as a result, operations for entry can be reduced. 

Yet another object of the present invention is to 
provide a method, apparatus and computer program for processing 
plural types of transactions using cards wherein a transaction 
screen is adapted to the contents of transactions of a 
transactor from the past to the present and his/her future 
schedule of transactions and a transaction efficient to a 
transactor can be performed. 

Still yet another, object of the present invention is 
to provide a method, apparatus and computer program for 
processing plural types of transactions using cards wherein the 
transaction information of companies of different industries 
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can be stored in a common server or in a chip of each IC card 
And as a result, an area for storing information and retrieval 
time can be reduced. 

According to the present invention, a variety of 
5 transactions with an institution such as an insurance company 
using one or plural cards are performed via a transaction 
processor such as personal computers inside/outside a shop, an 
ATM and a portable terminal. 

First, one insurance card of a transactor is 

10 inserted. A transactor in this case means an insurant who joins 
the insurance of an insurance company or a depositor with an 
account in a bank and a person who actually operates a 
transaction processor. A transaction screen consisting of 
transaction keys related to preset transactions proper to a 

15 transactor is displayed. The position, type, shape and color of 
keys on this transaction screen can be changed or added 
according to the contents of transactions of the transactor. A 
transaction key related to a transaction selected on the 
displayed transaction screen is pressed. As the types of 

2n transactions, loan, receipt of insurance and others are 

provided. Other cards such as a bank card, a credit card and 
another insurance card required for the transaction are 
received. No other cards may be required depending upon a 
transaction and plural cards may be required. 

25 Next, the personal identification numbers of the 

first inserted insurance card are entered. In case withdrawal 
occurs in the transaction of an insurance such as if money is 
withdrawn via a bank card for the payment of insurance, the 
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personal identification numbers of a card related to the 
withdrawal are entered. 

The contract of a new insurance, the receipt of 
insurance, loan, inquiry, the payment of insurance and the 
cancellation of an insurance are performed. Particularly, in 
the case of loan, a loan is performed based upon the total 
loanable limit sum of the received one or plural cards. In the 
case of inquiry, attribute information and transaction 
information of received cards are merged and the same 
information such as attribute information held by plural 
companies is displayed on the screen without a redundancy. In 
the case of the repayment of insurance, it is selected whether 
paid insurance is deposited in the bank account of a transactor 
or not and if the transactor has no account in a bank though a 
deposit is selected, an account for him/her is opened 
automatically. 

Further, in the contract of a new insurance, if a 
transactor signs or seals when he/she applies for a bank card 
or a credit card, a new contract can be made by entering a 
requirement in an application on the screen and answering a 
notice in case the sum of money equivalent to initial insurance 
is deposited in his/her bank account. If the balance of a 
transactor's bank account is less than insurance and insurance 
cannot be paid, the transactor is automatically joined in bank 
card loan or the credit of a credit card. If a transactor 
presses a transaction key showing the cancellation of his/her 
insurance, transaction keys for displaying total insurance and 
repayment and transaction keys for recommending the transactor 



to switch to another insurance are displayed on the screen. 

The present invention will be more apparent from the 
following detailed description, when taken in conjunction with 
the accompanying drawings, in which: 

Fig. 1 is a block diagram illustrating a system 
according to the present invention; 

Fig. 2 illustrates the flow of processing showing an 
embodiment for loan according to the present invention; 

Figs. 3A-3D illustrate the construction of an 
insurance card, an- attribute information record, an electronic 
money record and a transaction information table; 

Figs. 4A-4C illustrate transaction screens for an 
aged person and a newly married couple and an attribute file; 

Fig. 5 illustrates a personal identification numbers 
table managed by a server; 

Figs. 6A-6D illustrate respective transaction tables 
of an insurance company, a bank and a credit card issuance 
company and a loan upper limit file; 

Figs. 7A and 7B illustrate the flow of processing 
illustrating an embodiment for inquiry and an inquiry screen 
according to the present invention; 

Figs. 8A-8C illustrate respective transaction tables 
of an insurance company and a bank and a property/ debit table; 

Fig. 9 illustrates the flow of processing 
illustrating an embodiment for paying insurance according to 
the present invention; 
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Figs. 10A and 10B illustrate a screen for paying 
insurance in a transactor's bank account and an opened account 
deposit file; . / 

Fig. 11 illustrates the flow of processing 
illustrating an embodiment for a new contract according to the 
present invention; 

Figs. 12A and 12C illustrate a general transaction 
screen, a new contract screen and a contract conclusion/policy 
issuance screen; 

Fig. 13 illustrates the flow of processing showing an 
embodiment related to the voidance of an insurance contract 
according to the present invention; 

Figs. 14A-14E illustrate respective transaction 
tables of an insurance company and a bank, a balance comparison 
table and an opened account record; 

Fig. 15 illustrates a screen for selecting a method 
of paying insurance; 

Fig. 16 illustrates the flow of processing showing an 
embodiment related to the cancellation of an insurance contract 
according to the present invention; and 

Figs 17A-17C illustrate a transaction screen 
including a transaction key "CANCELLATION" , an another 
insurance switching guidance screen and a total 
insurance/canceled repayment guidance screen. 

Embodiments according to the present invention will 
be described below referring to the drawings. 
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Fig. 1 illustrates the constitution of a system 
According to the present invention. A server 4 connected to an 
attribute/ transaction database (DB) 1 for insurance companies, 
an attribute/transaction DB 2 for banks and an 
5 attribute/ transact ion DB 3 for credit card issuance companies 
and a plurality of client servers 6, 6' are connected via a 
network 5. The server 4 in this case means a computer in a 
common center managed by insurance companies, banks and credit 
card issuance companies. A display 10, a keypad entry 

10 apparatus 11, a card input apparatus 12 and an external storage 
apparatus consisting of a loan balance storage 13 and an 
inquiry contents storage 14 are connected to the client server 
6. This display 10 is provided with a touchpanel usually used 
in an ATM and can also function as the key entry apparatus 11. 

15 Each client server 6, 6' constitutes a terminal which 

a customer who is a transactor uses and constitutes an 
insurance transaction network under control by the server 4. 
Only two servers are shown in Fig. 1, however, in practice 
multiple servers are connected. Since an insurance transaction 

20 network can be constituted using well-known technology such as 
well-known electronic commerce (EC) , a detailed description 
thereof is omitted here. For example, a personal computer can 
be used as the client server 6 and the client server contains a 
general control apparatus 9 including a CPU, internal memory 8 

25 and a communication control apparatus 7 for controlling the 
communication of information via a network. 

The display 10 is a unit for displaying information 
visibly such as a CRT display unit or a liquid crystal display 
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and displays a transaction screen on which a customer who is a 
transactor transacts. 

The keypad entry apparatus II is used for entering 
information for selecting the contents of a transaction and 
5 entering the desired sum of a loan and a desired item to be 
inquired in addition to entering personal identification 
numbers and for example, a mouse, a joystick or a keypad can be 
used as the keypad entry apparatus. A loan upper limit sum 
table described later for setting the upper limit sum of a loan 

10 to a customer is stored in the loan balance storage 13. The 

inquiry contents storage 14 is a storage for storing a variety 
of contents of inquiry related to a received card. 

The general control apparatus 9 controls the overall 
client server 6 by a program input beforehand to enable 

15 operation. The control for displaying transaction keys related 
to transactions proper to a transactor on the display 10 , the 
control for inputting plural cards via the card input apparatus 
12 and the control for entering the personal identification 
numbers of the first input card via the keypad entry apparatus 

? n 11 are executed by this general control apparatus 9. Such 
processing can be executed by a software product beforehand 
installed. 

Next, the flow of processing for loan in this 
embodiment will be described referring to Figs. 2 to 6. Fig. 2 
25 illustrates the flow of processing for inputting the contents 
of a transaction to a client server 6, performing required 
processing and displaying the result of processing on the 
client server 6 . 
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An insurance card of a transactor is input via the 
-card input apparatus 12 in a step 21 in Fig. 2. The input 
insurance card is shown in Fig. 3A. As shown in- Fig. 3A, an 
insurance card 31 is inserted into ATM in the direction 3 2 to 
5 be input. In the upper part of the card, a linear magnetic 
stripe 3 3 extended horizontally for storing an attribute 
information record shown in Fig. 3B is embedded and immediately 
under the magnetic stripe, an IC chip 34 for storing an 
electronic money record shown in Fig. 3C is provided on the 

10 left side and an IC chip 35 for storing a transaction 

information table- shown in Fig. 3D is provided on the right 
side. As such constitution of the card such as the arrangement 
of the IC chips 34 and 3 5 and the arrangement of a contact with 
a card reader/writer can be realized by a well-Jcnown method. 

15 Therefore, the description thereof is omitted. 

In the above attribute information record shown in 
Fig. 3B, the information of the owner of a card such as his/her 
name, address and date of birth, . job and telephone number is 
stored. In the electronic money record shown in Fig. 3C, the 

/ a amount of electronic money to be stored in the IC chip 34 is 
stored. A format for storing electronic money is arbitrary, 
however, for example, each unit of money such as ten thousand 
yen and a thousand yen and the amount are stored. The 
transaction information table shown in Fig. 3D is attribute 

25 information related to a transactor and the type of a 

transaction related to the owner of an insurance card, the 
contents or the history is stored in a table format. When the 
insurance card of a transactor is input, a transaction screen 

10 
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consisting of transaction keys related to preset transactions 
proper to the transactor is displayed in a step 22. 

This transaction screen will be described below 
referring to Figs* 4A-4C. First, an attribute file shown in 
5 Fig. 4C based upon an input insurance card is obtained from the 
attribute/transaction DB 1 for insurance companies shown in 
Fig. 1 via the server 4 and the network 5. In this file of a 
customer, the transaction characteristics of the customer such 
as a marital status 46 and a main transaction 47 are set. A 

10 transaction screen in view of such characteristics of a 

customer is displayed on the display means 10. Fig. 4A shows 
such an example. A" transaction screen 41 shows a screen for Mr. 
Tanaka who is an aged person in a customers' file and as his 
main transaction is related to a pension, the frame and 

15 characters of a transaction key 42 is displayed larger than 

those of a transaction key 43 to highlight the transaction key 
42. If a transaction is to be promoted particularly in a month, 
it may be displayed large in the lower part of the screen as a 
transaction key 44. Fig. 4B shows a screen dedicated to Mr. & 

20 Mrs. Yamada who are a newly married couple. As Mr. & Mrs. 
Yamada have need for loan, loan is displayed with it 
highlighted as a transaction key 45. 

Next, the information of a transaction key related to 
a transaction selected by a transactor via the keypad entry 

25 apparatus 11 is entered on the transaction screen displayed on 
the display 10 via the general control apparatus 9 in a step 
23. Next, one or plural other cards required for the 
transaction are input via the card input apparatus 12 

11 
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sequentially in a step 24 and the respective personal 
identification numbers are entered via the keypad entry 
apparatus 11 in a step 25. Another card required. -f or the 
transaction is a card which companies join or a card by which 
5 bidirectional transaction processing is enabled in this system. 
It should be displayed on the screen in a step 24 which card is 
to be input so as to inform a transactor. 

Personal identification numbers are managed by the 
server 4 shown in Fig. 1 and are stored in a personal 

10 identification numbers table shown in Fig. 5- In this personal 
identification numbers table, the identification number of each 
card and respective personal identification numbers such as 
insurance card information 51 , bank card information 52 and 
credit card information 53 are stored. In this embodiment, in 

15 the case of Mr. Tanaka who is loaned, the personal 

identification numbers "3111" of his bank card are also entered 
in addition to the personal identification numbers "2111" of 
his insurance card. This time an example related to the loan is 
given, however, in the case of a transaction which is not 

2 n related to withdrawal such as inquiry, only the personal 

identification numbers of a first input card have only to be 
entered once. As the personal identification numbers of the 
insurance card, the bank card and the credit card of Mr. Yamada 
are all set to "5555", his personal identification numbers 

25 "5555" have only to be entered once in any transaction. Though 
it is not desirable in view of security that the same personal 
identification numbers are used, this system is managed as 
described above because it is not efficient to enter the same 

12 
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personal identification numbers plural times. Of course, this 
system may be constituted so that the same personal 
identification numbers are entered plural times... 

After personal identification numbers are entered, a 
desired sum of loan is entered via the keypad entry apparatus 
11 in a step 26. When the desired sum is entered, the order of 
companies by which a transactor is loaned can be determined. 
For example, if a desired sum of loan is one million yen and 
the interest of loan is low in the order of an insurance 
company, a bank and a credit card issuance company, five 
hundred thousand yen equivalent to the upper limit of a loan 
may be loaned by ah insurance company and five hundred thousand 
yen within the upper limit of a loan may be loaned by a bank. 
In this embodiment, the case that the sum equivalent to the 
upper limit of a loan is loaned will be described. After a 
desired sum of loan is entered, the upper limit of a loan is 
totalized in a step 27 and electronic money equivalent to the 
desired sum of loan is transferred to the insurance card 31. 

This flow will be described referring to Figs. 6A-6D. 
First, an insurance company transaction table shown in Fig. €A 
is sent from the attribute/transaction DB 1 for insurance 
companies to the server 4, a bank transaction table shown in 
Fig. 6B is sent from the attribute/ transaction DB 2 for banks 
to the server 4, a credit card issuance company transaction 
table shown in Fig. 6C is sent from the attribute/ transaction 
DB 3 for credit card issuance companies to the server 4, the 
loan upper limit file shown in Fig. 6D of a transactor is 
generated, the upper limit sums of loan 61, 62 and 63 of the 
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transactor in respective tables are totalized and the total sum 
ds displayed on the display means 10 via the client server 6. 
If the sum is within the desired sum of loan formerly entered, 
the sum of loan is transferred to the electronic money record 
34 of the insurance card shown in Fig. 3A via the card input 
apparatus 12. The sum of loan may be stored in the loan 
balance storage 13 shown in Fig. 1 as the balance of a loan via 
the card input means 12. 

As described above, when plural cards are inserted 
into an automatic transaction processor connected to an 
insurance company, transactions with plural companies can be 

processed once. 

Next, an inquiry transaction will be described 

referring to Figs. 1, 2, 4, 7A-7B and 8A-8C. 

As shown in Fig. 7A, the insurance card of a 
transactor and his/her card required for inquiry are input 
sequentially via the card input apparatus 12 in a step 71. In 
this embodiment, the property and debt of a transactor in an 
insurance company and a bank can be inquired at one time. 
Therefore, a bank card is input sequentially after an insurance 
card. Next, a transaction screen is displayed in a step 72 as 
in the step 22 in Fig. 2. A transaction key "INQUIRY" on this 
displayed transaction screen is entered via the keypad entry 
apparatus 11 or pressed on the touchpanel of the display 10 in 
a step 73. "INQUIRY" on this transaction screen as the one 
shown in Fig. 4B is selected causing the display of inquiry 
screen 700 illustrated in Fig. 7B. The inquiry screen 700 
includes PROPERTY 701, DEBT 702 and PROPERTY /DEBIT 703 keys. 
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If M PROPERTY / DEBT w key 703 of the inquiry screen 700 is entered 
or pressed in a step 74, the same method as in the step 73 is 
performed causing the display of PROPERTY/DEBT information. 
The same also occurs if any of the other keys, PROPERTY 7 01, or 
5 DEBT 702 are entered or pressed. As this transaction screen is 
like the format of the first transaction screen, the 
description is omitted here. Next, only the personal 
identification numbers of the first input insurance card of two 
input cards are entered via the keypad entry apparatus 11 in a 

10 step 75. It is because in the case of a transaction not related 
to withdrawal, payment or a transfer such as inquiry, the 
enhancement of the* operability of a transactor is regarded as 
more important rather than the enhancement of security by 
entering personal identification numbers corresponding to all 

15 cards that only personal identification numbers of a first 
inserted card are entered and the input of those of a next 
inserted card is omitted. As withdrawal or others is/are not 
performed using the card the personal identification numbers of 
which are not entered, a severe check by personal 

20 identification numbers of whether the owner of the card is a 
transactor or not is not required. 

Total insurance 81 which is a property item and the 
sum of loan to a contractor 82 which is a debt item in an 
insurance company transaction table shown in Fig. 8A, the 

25 balance of a deposit 83 which is a property item and the 
balance of card loan 84 which is a debt item in a bank 
transaction table shown in Fig. 8B are respectively extracted 
to generate a property/debt table shown in Fig. 8C in a step 
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76. At: this time, repeated "No.", "Name" and other items not 
related to "Property/ Debt" in Figs. 8A and 8B are used in the 
generated table nor displayed. As "No." and "Name" are the 
information of a transactor, they are not required to be 
5 displayed on the screen in this case and as "Transaction 

number" and "Account number" are only secondary information in 
relation to " Property/ Debt " , these are also not required to be 
displayed in this case. In response to the pressing or 
entering of the keys in the inquiry window 700 portions of the 

10 generated PROPERTY / DEBT table illustrated in Fig. 8C are 

displayed step 77. Thus, for example, if the PROPERTY key 7 01 
is pressed or entered all of the Property Items and the 
corresponding Sum of Property Items of the PROPERTY /DEBT table 
illustrated in Fig. 8C are displayed. However, if the card 

15 being processed is an insurance card then when the PROPERTY key 
7 01 is pressed or entered only the Total insurance property 
item and its corresponding Sum of Property item and the Total 
property and its corresponding Sum of Property item are 
displayed. If the DEBT key 701 is pressed or entered all of 

20 the Debt Items and corresponding Sum of Debt items of the 

PROPERTY/DEBT table illustrated in Fig. 8C are displayed. If 
the PROPERTY/ DEBT key 7 03 is pressed or entered the entire 
PROPERTY/DEBT table illustrated in Fig. 8C is displayed. When 
the contents of inquiry of property /debt are to be stored, the 

25 contents of inquiry can be stored in the inquiry contents 
storage 14 shown in Fig. 1. 

Next, the payment of insurance will be described 
referring to Figs. 1, 2, 6, 9 and 10. 
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The input of the insurance card of a transactor and 
the display of a transaction screen are performed in steps 91 
and 92 in Fig. 9 by the same method as in the steps 21 and 22 
shown in Fig. 2. A transaction key "PAYMENT OF INSURANCE" is 
pressed on the transaction screen in a step 93 by the same 
method as in the step 73 in Fig. 7. Next, a bank card for 
depositing insurance is input via the card input apparatus 12 
in a step 94. The card number may be entered via the keypad 
entry apparatus 11 in place of the card. Next, only the 
personal identification numbers of the first input insurance 
card are entered via the keypad entry apparatus 11 in a step 
95. In the case of a deposit , the personal identification 
numbers of an account for the deposit are not required to be 
entered. This is because money is paid in the bank account 
differently from withdrawal and others. 

Next, the sum of paid insurance sent from the 
insurance company transaction table shown in Fig. 6A via the 
network 5 is displayed on the transaction screen of the display 
10 in a step 96. It is displayed as in a display key 102 in the 
screen 101 in Fig. 10A. Next, an account in which the paid 
insurance is deposited is selected in a step 97. In Fig. 10A, a 
fixed deposit (annual interest: 1.5%) 103 and installment 
savings (annual interest: 0.7%) 104 are selected. After the 
selection, the transactor is prompted to further enter the sums 
to be deposited in the respective accounts. Hereby, the sums to 
be deposited in the respective accounts can be set freely in 
view of the respective annual interests. In this embodiment, as 
shown in the items of the contents of a transaction 105 and the 
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balance of a deposit 106 in Fig. 10B, eighteen million yen is 
specified so that it is deposited in a fixed deposit, two 
million yen is specified so that it is deposited. .in installment 
savings and the respective accounts for payment are 
5 automatically opened in a step 98. The number of the opened 
account may be given in the order of requests for opening an 
account sent to the server 4 shown in Fig. 1 and serial numbers 
may be given to an individual transactor for the simplification 
of management. 

10 Next, the contract of a new insurance will be 

described referring to Figs. 1, 3, 11 and 12. 

As shown* in Fig. 11, first the current card is input 
via the card input means 12 in a step 111. In this embodiment, 
a credit card issued by a credit card issuance company is 

15 input. Next, when the credit card is input, a transaction key 
showing a new contract on a general transaction screen 
displayed on the display means 10 is selected via the keypad 
entry apparatus 11 or others in a step 112 and the transaction 
screen for a new contract is displayed on the display means 10. 

?o In the uppermost location of the general transaction screen 

shown in Fig. 12 A, a transaction key for a credit card issuance 
company is displayed because a credit card is input. When the 
transaction key showing application for a new contract 121 is 
selected on the general transaction screen shown in Fig. 12A, a 

25 new contract screen is displayed as shown in Fig. 12B. The 

information of a requirement which is entered in an application 
122 on the screen is obtained in a step 113, the information of 
a requirement which is entered in a notice 12 3 under the 
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application is obtained in a step 114 and further, it is output 
as in a signature/ seal history 124 in a step 115 whether the 
information of a signature or seal of a transactor is stored or 
not- A signature and a seal in this signature/seal history mean 
those for the input credit card. 

Finally, a method of paying insurance is entered in a 
step 116 as shown in the payment of initial insurance 125. As 
payment by electronic money is selected in this case, an 
electronic money card is input afterward. When such a chain of 
processing is finished, the attribute/ transaction DB for 
insurance companies shown in Fig. 1 is updated via the network 
5 and the server 4" and the result of a new contract is output 
in a step 117. When a contract is made, words of the effect 
that the contract has been made are displayed on the display io 
as shown in 126 in Fig. 12C and the transactor is prompted to 
enter a method of receiving an insurance policy in a step 118. 
If the transactor desires sending of an insurance card to which 
the information of the insurance policy is input, he/she 
presses a transaction key 127 showing sending of the insurance 
card so that the insurance card to the chip 35 for storing 
transaction information shown in Fig. 3 A of which the 
information of the insurance policy is input is sent. If safe 
custody 128 is selected, the transactor's insurance policy is 
kept stored in the attribute/transaction DB for insurance 
companies and output to the transactor if necessary. 

Next, the voidance of an insurance contract will be 
described referring to Figs. 1, 13, 14 and 15. 

Fig. 13 shows the flow of the payment of insurance by 
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an automatic transaction processor. First, the information of 
fifty thousand yen stored in the item of insurance per month 
143 beforehand set by a transactor in an insurance company 
transaction table shown in Fig. 14 A is received in a step 131 
5 and next, the information of forty thousand yen stored in the 
item of the balance of his/her ordinary deposit 144 in a bank 
transaction table shown in Fig. 14B when the insurance is 
withdrawn is received in a step 132. This is automatically 
performed at the timing of a due date beforehand input by the 
10 transactor. Next, the set insurance per month and the balance 
of the transactors bank account when the insurance is 
withdrawn are compared in a step 13 3 and if the balance is more 
than the insurance, the contract is continued unconditionally 
in a step 134* 

15 If the balance is less than the insurance, a screen 

151 including warning 152 for selecting a method of paying 
insurance shown in Fig. 15 is displayed on the display 10 shown 
in Fig. 1. A method of paying insurance is selected on the 
displayed screen in a step 135, if payment by electronic money 

20 is selected by pressing a transaction key 153 shown in Fig. 15, 
the transactor's insurance card is input via the card input 
apparatus 12 in a step 136 and the sum equivalent to "-10,000 
yen" stored in the item of the shortfall of the balance 14 5 in 
a balance comparison table shown in Fig. 14C is paid by 

25 electronic money in a step 137. If no method of payment is set, 
the transactor is automatically joined in bank card loan or the 
credit of a credit card issuance company. If the transactor is 
joined in the bank card loan, his/her account for card loan is 
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opened in a step 138, the sum equivalent to the shortfall of 
the balance is supplied in a step 139 and the contract is 
continued, if the transactor is joined in the credit of a 
credit card issuance company, his/her account for the credit 
card is opened in a step 140, the sum equivalent to the 
shortfall of the balance is supplied in a step 141 and the 
contract is continued. 

When a transaction key 156 showing automatic entry 
preset by the server 4 shown in Fig. i is selected by a 
transactor, the automatic entry is itemized. The transactor can 
allocate the sum of a loan respectively to card loan and the 
credit of a credit ' card in view of each annual interest and can 
enter the respective allocated sums in the balance of card loan 
146 shown in Fig. 14D and the balance of a credit card 147 
shown in Fig. 14E by pressing both transaction keys 154 and 
155. Further, if no method of payment is set in the step 135 
and no payment is made, the contract is automatically voided in 
a step 142. 

Finally, the cancellation of an insurance contract 
will be described referring to Figs. 1, 16 and 17. 

As shown in Fig. 16, first the insurance card of a 
transactor is input via the card input means 12 in a step 161. 
Next, a transaction screen 17 1 including a transaction key 
"CANCELLATION" 172 shown in Fig. 17A is displayed on the 
display means 10 in a step 162 and the transaction key 
"CANCELLATION" on this transaction screen is selected by entry 
via the keypad entry means 11 or others in a step 163. As a 
result, guidance transaction keys shown in Fig. 17B for 
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switching to another insurance are displayed on the display 
means 10 in a step 164. If a transaction key 173 or a 
transaction key 174 shown in Fig. 17B is pressed^ the 
information related to the pressed transaction key is 
5 displayed. The size of the transaction keys for switching to 
another insurance is set beforehand so that it is larger than 
the size of the transaction key showing cancellation 175. When 
"CANCELLATION" is pressed at this time, total insurance 176, 
repayment 177 by cancellation and a transaction key 178 for 
10 guiding transactors in paying the repayment in their bank 
account are displayed in a step 165 as a total 

insurance/ canceled' repayment guidance screen shown in Fig. 17C. 
When this payment guidance transaction key 178 is selected, 
processing for cancellation is executed in a step 166, however, 

15 when a transaction key "RETURN TO PRECEDING SCREEN" 179 is 
selected, the insurance contact can be switched to another 
insurance on the another insurance switching guidance screen 
shown in Fig. 17B. 

In this embodiment, the case that a shortfall is paid 

20 by electronic money is described, however, if a premium is 

paid, a method reverse to the case is used. That is, electronic 
money stored in a transactor's insurance card input by him/her 
is stored in the server 4 via the network 5. 

Preferred embodiments related to a variety of 

25 insurance transactions according to the present invention are 
described above, however, the embodiments particularly related 
to payment can be applied to bank transactions and credit card 
transactions. The processing which is similar to the processing 
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according to the present invention can be also performed using 
ATM installed in a bank. 

As described in detail above, according to the 
present invention, plural cards issued by different industries 
5 can be utilized by one transaction terminal and a method of 
processing plural types of transactions using a card which 
enables the efficient performance of a variety of insurance 
transactions can be provided. 

While the present invention has been described in detail 
10 and pictorially in the accompanying drawings it is not limited 
to such details since many changes and modifications 
recognizable to those of ordinary skill in the art may be made 
to the invention without departing from the spirit and the 
scope thereof. 

15 
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CLAIMS 

1. A method of processing plural types of transactions 
by a transaction system for performing a variety- of 
transactions with plural institutions via a transaction 
processor using one or plural transaction cards, said method 
comprising the steps of: 

receiving a transaction card of a transactor; 

inputting and then checking identification numbers 
corresponding to said transaction card; 

displaying a screen which includes a plurality of 
transaction keys;- 

permittihg said transactor to select a transaction 
key of a desired transaction; 

receiving one or more other transaction cards 
required for said desired transaction; 

judging whether identification numbers corresponding 
to said one or more other transaction cards are required to be 
entered ; and 

executing transaction processing between one or more 
of said institutions based on the input of identification 
numbers of said transaction card or the input of identification 
numbers of said one or more other transaction cards required to 
be entered . 

2. A method according to Claim 1, further comprising the 
step of : 

if transaction processing of said one or more other 
transaction cards is not related to withdrawal of cash, 
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omitting input of personal identification numbers of said one 
or more other transaction cards when said transaction 
processing is executed . 

3, A method according to Claim 2, further comprising the 
step of: 

if transaction processing of said one or more other 
transaction cards is related to withdrawal of cash, inputting 
personal identification numbers of said one or more other 
transaction cards when said transaction processing is executed. 

4 • A method' according to claim 3 , further comprising the 
steps of : 

storing attribute information related to said 
transactor in said transaction card; arid 

changing a selective screen for transactions 
depending upon said attribute information. 

5. A method according to Claim 3, wherein said 
transactions include loan transactions from plural financial 
institutions, and wherein said method further comprises the 
steps of : 

when loan processing is selected, calculating a total 
loanable sum of plural transaction cards; 

displaying said total loanable sum; 

prompting said transactor to enter a sum to be 
loaned ; and 

executing loan transaction processing by allocating 
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the entered sum to plural financial institutions. 

6. A method according to Claim 1, wherein -said 
transactions include inquiry transactions from plural financial 
institutions , and wherein said method further comprises the 
steps of : 

when said inquiry transaction is selected, merging 
attribute information and transaction information of said 
transaction card; 

totalizing said attribute information held by said 
plural financial institutions; and 

displaying said totalized attribute information, 

7. A method according to Claim 1, wherein said 
transactions include a payment of insurance transactions, and 
wherein said method further comprises the steps of: 

when transaction of payment of insurance is selected, 
determining whether said payment of insurance is to be 
deposited in a bank; and 

when said payment of insurance is to be deposited in 
said bank, automatically opening an account of said bank. 

8. A method according to Claim 7, further comprising the 
steps of : 

when said in said bank account is opened, receiving 
information of an application entered by said transactor; and 

if signature or a seal by said transactor of another 
bank card or a credit card has been stored, executing a 
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transaction processing for a new insurance contract based upon 
said signature or seal and a balance of said account of said 
transaction. ./ 

9. A method according to Claim l, wherein said 
transactions include payment of insurance transactions, and 
wherein said method further comprises the step of: 

if a balance of a bank account of said transaction is 
short of a required payment, executing transaction processing 
for obtaining a bank card loan or a credit card issued by a 
credit card issuance company. 

10. A method according to Claim 1, wherein said 
transactions include cancellation transactions for cancelling 
insurance, and wherein said method further comprises the step 
of: 

when cancellation transaction is selected and 
information for cancelling insurance is entered by said 
transactor, executing transaction processing for transferring a 
total insurance or repayment to a bank account of said 
transactor . 

11. A transaction system for performing a variety of 
transactions with plural institutions using one or plural 
transaction cards, said transaction system comprising: 

a server; 

a database connected to said server, said database 
stores attribute information of transactions which can be 
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conducted by transactors with said institutions; 

a plurality of transaction processors for permitting 
a transactor to perform transactions with said institutions 
using one or plural transaction cards; and 

a network which interconnects said server with said 
transaction processors, 

wherein each transaction processor receives a 
transaction card of a transactor, inputs and then checks 
identification numbers corresponding to said transaction card 
based on attribute information retrieved from said database by 
said server, displays a screen which includes a plurality of 
transaction keys based on attribute information retrieved by 
said server, permits said transactor to select a transaction 
key. of a desired transaction, receives one or more other 
transaction cards required for said desired transaction, judges 
whether identification numbers corresponding to said one or 
more other transaction cards are required to be entered based 
upon attribute information retrieved by said server from said 
database and executes transaction processing between one or 
more of said institutions based on attribute information 
retrieved by said server from said database and the input of 
identification numbers of said transaction card or the input of 
identification numbers of said one or more other transaction 
cards required to be entered. 

12. A transaction system according to Claim 11, wherein 
said transaction processor, if transaction processing of said 
one or more other transaction cards is not related to 
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withdrawal of cash, omits input of personal identification 
numbers of said one or more other transaction cards when said 
transaction processing is executed. 

13. A transaction system according to Claim 12, wherein 
said transaction processor, if transaction processing of said 
one or more other transaction cards is related to withdrawal of 
cash, inputs personal identification numbers of said one or 
more other transaction cards when said transaction processing 
is executed. 

14. A transaction system according to claim 13, wherein 
said transaction processor stores attribute information related 
to said transactor in said transaction card, and changes a 
selective screen for transactions depending upon said attribute 
information. 



15. A transaction system according to Claim 13, wherein 
said transactions include loan transactions from plural 
financial institutions, and wherein said transaction processor, 
when loan processing is selected, calculates a total loanable 
sum of plural transaction cards, displays said total loanable 
sum, prompts said transactor to enter a sum to be loaned, and 
executes loan transaction processing by allocating the entered 
sum to plural financial institutions. 

16. a transaction system according to Claim 11, wherein 
said transactions include inquiry transactions from plural 
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financial institutions, and wherein said transaction processor, 
when said inquiry transaction is selected, merges attribute 
information and transaction information of said transaction 
card, totals said attribute information held by said plural 
financial institutions, and displays said totalized attribute 
information. 

17. A transaction system according to Claim 11, wherein 
said transactions include a payment of insurance transactions, 
and wherein said transaction processor, when transaction of 
payment of insurance is selected, determines whether said 
payment of insurance is to be deposited in a bank, and when 
said payment of insurance is to be deposited in said bank, 
automatically opens an account of said bank. 

18. A transaction system according to Claim 17, wherein 
said transaction processor, when said in said bank account is 
opened, receives information of an application entered by said 
transactor, and if signature or a seal by said transactor of 
another bank card or a credit card has been stored in said 
database, executes a transaction processing for a new insurance 
contract based upon said signature or seal and a balance of 
said account of said transaction. 

19. A transaction system according to Claim 11, wherein 
said transactions include payment of insurance transactions, 
and wherein said transaction processor, if a balance of a bank 
account of said transaction is short of a required payment, 
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executes transaction processing for obtaining a bank card loan 
or a credit card issued by a credit card issuance company. 



20. A transaction system according to Claim 11, wherein 
said transactions include cancellation transactions for 
cancelling insurance, and wherein said transaction processor, 
when cancellation transaction is selected and information for 
cancelling insurance is entered by said transactor, executes 
transaction processing for transferring a total insurance or 
repayment to a bank account of said transactor. 

21. A computer program stored on a storage medium for 
execution in a transaction system to cause said transaction 
system to perform a variety of transactions with plural 
institutions using one or plural transaction cards, said 
computer program when executed in said transaction system 
causes said transaction system to perform the steps of: 

receiving a transaction card of a transactor; 
inputting and then checking identification numbers 
corresponding to said transaction card; 

displaying a screen which includes a plurality of 
transaction keys; 

permitting said transactor to select a transaction 
key of a desired transaction; 

receiving one or more other transaction cards 
required for said desired transaction; 

judging whether identification numbers corresponding 
to said one or more other transaction cards are required to be 
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entered ; and 

executing transaction processing between one or more 
of said institutions based on the input of identification 
numbers of said transaction card or the input of identification 
numbers of said one or more other transaction cards required to 
be entered . 

22. A computer program according to Claim 21, wherein 
said computer program when executed further causes said 
transaction system to perform the step of: 

if transaction processing of said one or more other 
transaction cards is not related to withdrawal of cash, 
omitting input of personal identification numbers of said one 
or more other transaction cards when said transaction 
processing is executed. 

23. A computer program according to Claim 22, wherein 
said computer program when executed further causes said 
transaction system to perform the step of: 

if transaction processing of said one or more other 
transaction cards is related to withdrawal of cash, inputting 
personal identification numbers of said one or more other 
transaction cards when said transaction processing is executed. 

24. A computer program according to claim 23, wherein 
said computer program when executed further causes said 
transaction system to perform the steps of: 

storing attribute information related to said 
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transactor in said transaction card; and 

changing a selective screen for transactions 
depending upon said attribute information. 



25. A computer program according to Claim 23 , wherein 
said transactions include loan transactions from plural 
financial institutions, and wherein said computer program when 
executed further causes said transaction system to perform the 
steps of: 

when loan processing is selected, calculating a total 
loanable sum of plural transaction cards; 

displaying said total loanable sum; 

prompting said "transactor to enter a sum to be 
loaned; and 

executing loan transaction processing by allocating 
the entered sum to plural financial institutions. 

26. A computer program according to Claim 21, wherein 
said transactions include inquiry transactions from plural 
financial institutions, and wherein said computer program when 
executed further causes said transaction system to perform the 
steps of: 

when said inquiry transaction is selected, merging 
attribute information and transaction information of said 
transaction card; 

totalizing said attribute information held by said 
plural financial institutions; and 

displaying said totalized attribute information. 
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27. A computer program according to Claim 21, wherein 
said transactions include a payment of insurance transactions, 
and wherein said computer program when executed further causes 
said transaction system to perform the steps of: 

when transaction of payment of insurance is selected , 
determining whether said payment of insurance is to be 
deposited in a bank; and 

when said payment of insurance is to be deposited in 
said bank, automatically opening an account of said bank. 

28. A method according to Claim 27, wherein said computer 
program when executed further causes said transaction system to 
perform the steps of: 

when said in said bank account is opened, receiving 
information of an application entered by said transactor; and 

if signature or a seal by said transactor of another 
bank card or a credit card has been stored, executing a 
transaction processing for a new insurance contract based upon 
said signature or seal and a balance of said account of said 
transaction. 

29. A computer program according to Claim 21, wherein 
said transactions include payment of insurance transactions, 
and wherein said computer program when executed further causes 
said transaction system to perform the step of: 

if a balance of a bank account of said transaction is 
short of a required payment, executing transaction processing 
for obtaining a bank card loan or a credit card issued by a 
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credit card issuance company. 



30. A computer program according to Claim .21, wherein 
said transactions include cancellation transactions for 
cancelling insurance, and wherein said computer program when 
executed further causes said transaction system to perform the 
step of: 

when cancellation transaction is selected and 
information for cancelling insurance is entered by said 
transactor, executing transaction processing for transferring a 
total insurance or repayment to a bank account of said 
transactor . 

31. A computer program according to claim 21, wherein 
said transaction system comprises: 

a server connected to a database which stores 
attribute information; 

a plurality of transaction processors each 
transaction processor executes transaction processing with said 
institutions using one or more transaction cards based on input 
from a transactor and attribute information retrieved by said 
server from said database; and 

a network which interconnects said server and said 
transaction processors . 

32. A computer program according to claim 31 wherein said 
computer program is executed by said server. 
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33. A computer program according to claim 31, wherein 
said computer program is executed in each of said transaction 
processors. 

34. A transaction processor for use in a transaction 
system for performing a variety of transactions with plural 
institutions using one or plural transaction cards, said 
transaction system includes a server, a database connected to 
said server, said database stores attribute information of 
transactions which can be conducted by transactors with said 
institutions, a plurality of said transaction processors and a 
network which interconnects said server with said transaction 
processors, said transaction processor comprising: 

a display; 

a card reader; 

an input apparatus; and 

a controller with controls said display, card reader 
and input apparatus such that said transaction processor 
receives a transaction card of a transactor, inputs and then 
checks identification numbers corresponding to said transaction 
card based on attribute information retrieved from said 
database by said server, displays a screen which includes a 
plurality of transaction keys based on attribute information 
retrieved by said server, permits said transactor to select a 
transaction key of a desired transaction, receives one or more 
other transaction cards required for said desired transaction, 
judges whether identification numbers corresponding to said one 
or more other transaction cards are required to be entered 



based upon attribute information retrieved by said server from 
said database and executes transaction processing between one 
or more of said institutions based on attribute information 
retrieved by said server from said database and the input of 
identification numbers of said transaction card or the input of 
identification numbers of said one or more other transaction 
cards required to be entered. 

35. A transaction processor according to Claim 34 , 
wherein said controller, if transaction processing of said one 
or more other transaction cards is not related to withdrawal of 
cash, omits input of personal identification numbers of said 
one or more other transaction cards when said transaction 
processing is executed. 

36. A transaction processor according to Claim 35, 
wherein said controller, if transaction processing of said one 
or more other transaction cards is related to withdrawal of 
cash, inputs personal identification numbers of said one or 
more other transaction cards when said transaction processing 
is executed. 

37. A transaction processor according to claim 36, 
wherein said controller stores attribute information related to 
said transactor in said transaction card, and changes a 
selective screen for transactions depending upon said attribute 
information . 
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38. A transaction processor according to Claim 36, 
wherein said transactions include loan transactions from plural 
financial institutions, and wherein said controller, when loan 
processing is selected, calculates a total loanable sum of 
plural transaction cards, displays said total loanable sum, 
prompts said transactor to enter a sum to be loaned, and 
executes loan transaction processing by allocating the entered 
sum to plural financial institutions. 

39. A transaction processor according to Claim 34, 
wherein said transactions include inquiry transactions from 
plural financial institutions, and wherein said controller, 
when said inquiry transaction is selected, merges attribute 
information and transaction information of said transaction 
card, totals said attribute information held by said plural 
financial institutions, and displays said totalized attribute 
information. 

40* A transaction processor according to Claim 34, 
wherein said transactions include a payment of insurance 
transactions, and wherein said controller, when transaction of 
payment of insurance is selected, determines whether said 
payment of insurance is to be deposited in a bank, and when 
said payment of insurance is to be deposited in said bank, 
automatically opens an account of said bank. 

41. A transaction processor according to Claim 40, 
wherein said controller, when said in said bank account is 
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opened, receives information of an application entered by said 
transactor, and if signature or a seal by said transactor of 
another bank card or a credit card has been- stored in said 
database, executes a transaction processing for a new insurance 
contract based upon said signature or seal and a balance of 
said account of said transaction. 

42. A transaction processor according to Claim 34, 
wherein said transactions include payment of insurance 
transactions, and wherein said controller, if a balance of a 
bank account of said transaction is short of a required 
payment , executes transaction processing for obtaining a bank 
card loan or a credit card issued by a credit card issuance 
company . 

43. A transaction processor according to Claim 34, 
wherein said transactions include cancellation transactions for 
cancelling insurance, and wherein said controller, when 
cancellation transaction is selected and information for 
cancelling insurance is entered by said transactor, executes 
transaction processing for transferring a total insurance or 
repayment to a bank account of said transactor. 

44. A method according to Claim 1, wherein each 
transaction card comprises: 

a magnetic stripe for storing attribute information 
of transactions which can be conducted by said transactor with 
said institutions ; 
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a first integrated circuit (IC) chip for storing a 
record of electronic money in possession of said transactor; 
and 

a second IC chip which stores a record of 
transactions conducted by said transactor with said 
institutions . 

45. A transaction system according to Claim 11 , wherein 
each transaction card comprises: 

a magnetic stripe for storing attribute information 
of transactions which can be conducted by said transactor with 
said institutions ; - 

a first integrated circuit (IC) chip for storing a 
record of electronic money in possession of said transactor; 
and 

a second IC chip which stores a record of 
transactions conducted by said transactor with said 
institutions . 

46. A computer program according to Claim 21, wherein 
each transaction card comprises: 

a magnetic stripe for storing attribute information 
of transactions which can be conducted by said transactor with 
said institutions ; 

a first integrated circuit (IC) chip for storing a 
record of electronic money in possession of said transactor; 
and 

a second IC chip which stores a record of 
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transactions conducted by said transactor with said 
institutions . 

47. A transaction processor according to Claim 34, 
wherein each transaction card comprises: 

a magnetic stripe for storing attribute information 
of transactions which can be conducted by said transactor with 
said institutions; 

a first integrated circuit (IC) chip for storing a 
record of electronic money in possession of said transactor; 
and 

a second* IC chip which stores a record of 
transactions conducted by said transactor with said 
institutions. 



4 
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